Improve label versions triaging #1613
Conversation
Co-authored-by: Stan Ulbrych <[email protected]>
| version under development would now be :samp:`3.{N+1}.0a1`. | ||
|
|
||
| To indicate that the labelling is correct and the extension is | ||
| approved, the :gh-label:`triaged` label could also be applied. |
There was a problem hiding this comment.
| approved, the :gh-label:`triaged` label could also be applied. | |
| approved, the :gh-label:`triaged` label can also be applied. |
Little grammar nit
| @@ -97,9 +98,45 @@ These labels are used to indicate which versions of Python are affected. | |||
| The available version labels (with the form :samp:`3.{N}`) are updated | |||
| whenever new feature releases are created or retired. | |||
|
|
|||
| Triagers may adhere to the following recommendations: | |||
There was a problem hiding this comment.
| Triagers may adhere to the following recommendations: | |
| Recommendations on when to use the labels: |
There was a problem hiding this comment.
I don't want to make it more mandatory or recommend than it is. I feel that "Guidelines" is too strong for such recommendations in how I see it. Well.. there is maybe one exception when we add a version label to a feature but all other points are really optional
There was a problem hiding this comment.
I modified the suggestion to "recommendations"
There was a problem hiding this comment.
To the point and linkable:
| Triagers may adhere to the following recommendations: | |
| Recommendations | |
| --------------- |
| @@ -97,9 +98,45 @@ These labels are used to indicate which versions of Python are affected. | |||
| The available version labels (with the form :samp:`3.{N}`) are updated | |||
| whenever new feature releases are created or retired. | |||
|
|
|||
| Triagers may adhere to the following recommendations: | |||
There was a problem hiding this comment.
To the point and linkable:
| Triagers may adhere to the following recommendations: | |
| Recommendations | |
| --------------- |
| the :gh-label:`type-bug` label as knowing which versions are affected | ||
| does not give more information. | ||
|
|
||
| Once the bug is resolved, one can optionally add the version labels for |
There was a problem hiding this comment.
More direct:
| Once the bug is resolved, one can optionally add the version labels for | |
| Once the bug is resolved, you can optionally add the version labels for |
| Once the bug is resolved, one can optionally add the version labels for | ||
| the affected versions. This helps readers in knowing whether their issue | ||
| has been solved for their Python version. |
There was a problem hiding this comment.
So do you add the version labels for the versions where it has been fixed, or those where it's still an outstanding issue?
There was a problem hiding this comment.
I personally don't add them because it's usually rare that I actually take very old issues, fix them, and close them. But I think it could be helpful for people who don't want to look at the commit itself and check to which branch it belongs. OTOH, we could just add a comment (Victor usually adds a comment saying in which commit it was fixed, but we could add "fixed in 3.X by commit ...".
This is something I actually wanted feedback on. Which would be the best for us?
There was a problem hiding this comment.
I think leave it out, labelling closed issues isn't the best use of limited volunteer time, and I doubt closed issues are checked very much. We have the linked PRs if you want to check what fixes were actually made.
| the affected versions. This helps readers in knowing whether their issue | ||
| has been solved for their Python version. | ||
|
|
||
| - EOL version labels should be removed when possible but there is no need |
There was a problem hiding this comment.
| - EOL version labels should be removed when possible but there is no need | |
| - Labels for end-of-life versions should be removed when possible but there is no need |
| - EOL version labels should be removed when possible but there is no need | ||
| to explicitly go through old issues to remove such labels. | ||
|
|
||
| - Otherwise, add the corresponding version label(s) and remember to |
There was a problem hiding this comment.
| - Otherwise, add the corresponding version label(s) and remember to | |
| - Otherwise, add the corresponding version labels and remember to |
| - If we are currently in the *beta* period of :samp:`3.{N}.0` and | ||
| if a feature was implemented in its *alpha* period but requires a | ||
| non-trivial extension (hence a new *feature* issue), this new | ||
| feature issue is given the :samp:`3.{N}` label as the latest | ||
| version under development would now be :samp:`3.{N+1}.0a1`. | ||
|
|
||
| To indicate that the labelling is correct and the extension is | ||
| approved, the :gh-label:`triaged` label could also be applied. |
There was a problem hiding this comment.
Hmm, not sure if we need this? And I'm not sure about the triage label suggestion, it doesn't really say anything more than "issue is accepted by a triager".
There was a problem hiding this comment.
Actually, it's for a visual tag. Sometimes I don't remember the issues I've triaged. And if I see an issue with weird label I would say "oh this one could have been mistriaged maybe". But with a triaged label, I know that I don't need to change the labels (same for when I lack a topic-* or a directory for an issue; when there is just "type-bug" it's kind of .. hard to know that there is actually a project associated to the issue; projects can't be seen on the issue page)
Some people asked me about how I actually apply my labels while triaging and I think I could actually share my workflow in the devguide instead for future triaging. I especially think that it's not necessary for bugs that span across all active versions to be labelled with the all labels... Ideally, I would have wanted a 3.X+ tag which implies that the bug started appearing in 3.X, and a bot would be able to automate the labels every time a new one is added but this would be a separate issue.
cc @hugovk
📚 Documentation preview 📚: https://cpython-devguide--1613.org.readthedocs.build/